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Field of the invention 

5 This invention relates to a method for generating an on- 
screen menu. 

Background 

10 Audio-visual contents of data storage media, e.g. Digital 
Versatile Discs (DVD) for video applications, usually 
contain menu data for various applications, e.g. to enable 
a user to select specific content of the medium. The menu 
data are used for rendering the menu on a display screen. 

15 Often so-called multi-page menus are used, where each 

possible state of the menu is represented by a full-screen 
image that is overlaid as a separate layer to the video 
picture. The menu layer is usually transparent, except for 
the displayed menu items. 

20 

In state-of-the-art menus the menu items basically consist 
of a number of buttons and non-button objects. Each button 
is assigned an on-screen position by the content author and 
can be navigated and activated by the user, e.g. via a 
25 remote control. Each button is associated a state, which 
can either be the x normal' (or 'unselected' ) state, the 
'selected' state or the 'activated' state. Each button can 
provide a different visual representation in each state in 
order to give the user feedback. 

30 

However, these kinds of menus are rather static as there is 
no way to dynamically add or remove buttons from the 
screen, without re-rendering the whole screen. For content 
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authors such more sophisticated menu features would be 
desirable, for example for the design of sub-menus. In such 
a case, additional buttons dynamically appear and disappear 
on the screen through user interaction. 

The invention provides means to generate such dynamic 
menus . 



10 Summary of the Invention 

The present invention is based on the assumption that the 
different menu items and buttons of an on-screen menu are 
rendered separately, not pagewise, on top of a static or 
15 dynamic background that may remain visible. "Rendering" 
means generating values for display pixels. 

According to the invention, each button is assigned an 
additional state, which can either be the 'enabled' or the 

20 'disabled' state. As a general rule, this state defines the 
rendering behaviour of the button. Buttons that are in the 
'enabled' state are typically displayed on the screen, 
while buttons that are in the 'disabled' state are not 
rendered and therefore not displayed. Enabled buttons may 

25 also be transparent though. 

The user can navigate only buttons that are in the 
'enabled' state, and their well known 'normal', 'selected' 
or 'activated' state is only valid within the 'enabled' 
30 state. The user cannot navigate buttons that are in the 

'disabled' state. Any attempt to do that is ignored by the 
decoder according to the invention. 
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Each button within the menu is assigned an on-screen area 
and a unique identifier. Usually the on-screen area of 
buttons will be rectangular, or a combination of 
rectangular partial areas. 

According to the current invention, buttons are organized 
in groups, and all buttons obey to certain rules, which are 
described in the following. 

The number of buttons belonging to one button group 
can be one or more. There are no empty button groups. 
A button cannot belong to more than one button group. 
The on-screen area of any button belonging to a first 
button group does not overlap with the on-screen area 
of any other button that is not belonging to the same 
button group. 

- Each button within a button group must be in one of 
the two states: 'enabled' or 'disabled' . 

- Each button is assigned an initial state, which is 
either the "enabled' or the 'disabled' state. 

- Not more than one button within a button group can be 
in the 'enabled' state at a time, i.e. rendered on the 
screen. Note that the 'enabled' state does not imply 
user-visibility; e.g. an enabled button is not visible 
to the user if it is represented only through 
transparent pixels. 

For each button within a button group neighbourhood 
information for button navigation can be defined, 
saying e.g. which other button to select when the user 
presses the LEFT, RIGHT, UP or DOWN button. This 
neighbourhood information is only valid when the 
button is in the 'enabled' state. The user cannot 
navigate to disabled buttons. 
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- The on-screen areas of a first button of a first 
button group and a second button of the same group, 
i.e. their visible representations, may overlap. They 
will not be visible simultaneously since they belong 
5 to the same button group, and only one of them can be 

in the 'enabled' state at a time. 

Further, a new command is defined, based on the invention. 
This command can e.g. be associated with a button, and it 

10 is used to dynamically switch between the 'enabled' and the 
'disabled' state of another button. In state-of-the-art 
menus, activating a button already may encompass the 
execution of one or more commands. The proposed command is 
activated in the same way and is therefore compatible with 

15 the state-of-the-art framework. Other effects of activating 
a button are commonly that the button changes its 
appearance, * colour etc. 

One aspect of the invention is the definition of a command 
20 for enabling or disabling buttons. The information about 
which button to enable or disable is provided through the 
button identifier as a parameter of the command. 
For each button there can be defined one or more button 
commands that are executed upon activation of the button. 
25 The command or set of commands associated with a button is 
also referred to as a button handler. The execution of 
button commands is only possible when the button is in the 
'enabled' state. There may be 'empty' buttons however that 
have no associated button command. The disabling of a 
30 button may clear the button visibility by substituting it 
with transparent pixels. 
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The inventive button command does usually not change the 
'enabled' or 'disabled' state of its own button. This means 
that if an enabled button is activated, the corresponding 
button command that is executed upon activation may switch 

5 the 'enabled' /' disabled' state of other buttons, but it may 
not switch its own button to the 'disabled' state, except 
when its button handler has already scheduled the selection 
of another button. There may however other commands be 
executed that comprise e.g. disabling the whole menu. 

10 Enabling one button of a group implicitly disables all 
other buttons within that group. 



For each button group a display area is defined where its 
buttons may be rendered. This area is in the following 

15 called a button group area. It is usually rectangular, but 
can in principle have other shapes. The visible button may 
have any shape as long as it is within its respective 
button group area. E.g. it is possible to render a circular 
button within a rectangular area. The screen pixels that 

20 belong to a button group area, but not to an enabled button 
within said button group area, are rendered transparent. 

For button group areas according to the invention it is 
characteristic that no possible button position within a 

25 button group may overlap with any possible button position 
of another button group, so that the button group areas of 
different button groups may not overlap at all. 
This means that the screen can be considered as a number of 
non-overlapping button group areas. When the state of any 

30 of the buttons of a button group changes, the decoder 
according to the invention reads the position of the 
respective button group area from a storage medium, usually 
an internal memory, and then re-renders the area. For each 
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group only the enabled button is rendered, wherein the 
corresponding button group area may comprise any number of 
transparent pixels . 

Advantageously, re-rendering of a button group area never 
5 modifies pixels belonging to any other button group area, 
since different button group areas may not overlap. This 
allows easier decoders. Further, it allows easier 
programming of menus, and particularly easier verification 
of the respective programming code, e.g. due to static 
10 button positions and static neighborhood relations. 

In detail, there are three possibilities for button group 
areas, as described in the following. They are specialized 
versions of a general case. 

15 

The first possibility is the general case as described 
above, wherein a button group area may comprise several 
non-overlapping partial areas, and in each button group 
area a button belonging to the respective button group may 

20 be rendered visible. Therefore a button that belongs to a 

button group is usually associated with one partial area of 
its button group area, and then not more than one of the 
partial areas of a button group may contain an enabled 
button. In principle it is possible though that an enabled 

25 button is present in more than one of the partial areas of 
its button group, so that a single button may consist of 
several equivalent parts. When the state of any of the 
buttons of a button group changes, the decoder according to 
the invention reads the positions of the partial areas of 

30 the respective button group from a storage medium and 

renders all partial areas new. Particularly, it renders not 
more than one visible button, namely the enabled button. 
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The second possibility is that a button group area is a 
contiguous area, e.g. a rectangular area. This means that a 
cohesive area is defined for each button group, which area 
comprises all possible positions of buttons belonging to 

5 that button group. As mentioned before, the areas that 

belong to different button groups may not overlap, and the 
visible button needs not necessarily fill the allowed area, 
i.e. the button needs not have the size and shape of the 
button group area, but it must be fully within the area 

10 corresponding to its group. Therefore, buttons belonging to 
different groups may not overlap. Further, it is easy to 
fully delete a first button belonging to a first button 
group when displaying a second button belonging to the same 
button group, because in this case only the button group 

15 area belonging to the respective button group needs to be 
re-rendered, which is a single contiguous area; it is not 
necessary to re-render other parts of the screen. Thus, no 
remains of the previously shown button are visible. All 
buttons within a button group use the same on-screen area. 

20 This is the preferred possibility. 

The third possibility is that all buttons of a button group 
have identical areas, i.e. button size and position on the 
screen. This is the easiest case, with respect to decoder 

25 implementation, menu programming and verification, because 
rendering a button that belongs to a certain button group 
necessarily deletes another button of the same button group 
that was previously visible on the same position. Though it 
provides a less flexible menu than the other two 

30 possibilities. 

In principle a button group can also contain non-button 
objects, i.e. menu items that are visible but not 
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selectable. A non-button object that belongs to a button 
group has a state assigned, the state being 'enabled' or 
"disabled' , and can be rendered visible only if it is 
enabled. Enabling and disabling is done through button 
handlers associated with menu buttons. 

The invention provides more sophisticated menu features, as 
e.g. demanded by content authors, which features allow easy 
decoding. In particular, the invention provides means to 
generate dynamic menus, wherein buttons can be dynamically 
removed or added to a menu. 

With the invention, a content author is able to easily 
define hierarchical menus and sub-menus being represented 
by a flat data structure. Particularly the programming and 
verification of menus is easier than with known methods. An 
advantage of the invention is that the graphics decoder 
needs not consider the whole menu for any menu operation, 
but it may simply handle isolated button groups instead. 
The data that describe the initial menu structure are read 
from a storage medium, usually a removable storage medium, 
e.g. optical disc, and are then stored on a temporary 
storage medium, e.g. memory, which is connected to the 
decoder. When the menu is operated, the variables within 
the temporary storage hold the current state. 

When a button is invisible, this can either mean that it is 
disabled and can therefore not be selected or activated, or 
it is enabled and marked invisible, e.g. has a special flag 
or only transparent pixels. In the latter case it can be 
selected, and usually will be automatically activated upon 
selection, so that associated commands are executed and a 
visible button is selected. It is also possible to 
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concatenate invisible buttons, as long as the last button 
command selects a visible button. 

Claim 1 discloses a method for generating a menu using such 
5 button groups. An apparatus that utilizes the inventive 

method is disclosed in claim 8. A storage medium holding a 
respective data structure is disclosed in claim 12. 

Further objects , features and advantages of the invention 
10 will become apparent from a consideration of the following 
description and the appended claims when taken in 
connection with the accompanying drawings. 



15 Brief description of the drawings 

Exemplary embodiments of the invention are described with 
reference to the accompanying drawings, which show in 

20 Fig.l a menu screen with disabled submenus; 

Fig. 2 a menu screen with enabled first submenu; 

Fig. 3 a menu screen with enabled second submenu; 

Fig. 4 an authoring option for submenu selection; 

Fig. 5 a menu screen with selected submenu item; 
25 Fig. 6 a button group area according to first possibility; 

Fig. 7 a button group area according to second possibility; 

Fig. 8 a button group area according to third possibility; 

Fig. 9 a screen with menu icon; 

Fig. 10 a screen with menu icon and enabled menu; 
30 Fig. 11 an initial multi-activation menu screen after first 
activation of a feature type button; 
Fig. 12 a multi-activation menu screen after second 
activation of a feature type button; 
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Fig. 13 a multi-activation menu screen after third 
activation of a feature type button; 

Fig- 14 a menu screen with conditionally enabled item; 
Fig. 15 initial view of a breadcrumb menu; 
5 Fig. 16 buttons included in initial view of a breadcrumb 
menu; 

Fig. 17 and Fig. 18 transition from first to second view in 
breadcrumb menu; 

Fig. 19 and Fig. 20 transition from second to third view in 
10 breadcrumb menu; and 

Fig. 21, 22 and 23 appearances of selected and unselected, 
but previously selected, buttons in breadcrumb menu, during 
transition to submenu. 

15 

Detailed description of the invention 

Fig.l shows the initial view of a menu page on a display 
screen s, with only an "Audio Language" button VB1 and a 

20 "Subtitle Language" button VB2 enabled and visible. The 
other buttons BG belong to submenus of either of the 
visible buttons and are invisible, as defined through a 
data-segment that describes the menu and that is contained 
in a bitstream on the medium. According to the invention, 

25 these buttons BG belong to separate button groups and are 
initially disabled, and thus invisible. Moreover, also the 
two visible buttons VBl,VB2 may belong to separate button 
groups. The data segment can be called interactive 
composition segment (ICS) . In the initial view shown in 

30 Fig.l none of the visible buttons VB1,VB2 is activated. 

Usually one of the visible buttons is initially selected by 
default. If in the shown case the user presses e.g. the 
RIGHT button on the remote, nothing would change because 
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there is no button activated yet. Generally, if 
neighbourhood relations are defined that lead to disabled 
buttons , the decoder ignores the relations as long as the 
neighbour buttons are disabled. Pressing e.g. the UP or . 
5 DOWN button would select either of the visible buttons 
VB1,VB2. Activating the "Audio Language" button VB1 by 
selecting the button VBl and pressing on a remote e.g. an 
"OK" button would lead to a menu display modif ication, as 
shown in Fig. 2. 

10 

In Fig. 2 the "Audio Language" button VBl is activated, and 
the button commands associated with it enable the buttons 
BGA to the right. Consequently, these buttons BGA are 
rendered visible, allowing to select and activate one of 
15 them, and thus to select an audio language. 



Fig. 3 shows a situation where e.g. starting from Fig. 2 the 
"Audio Language" button VBl was not activated, but the DOWN 
button was pressed so that the "Subtitle Language" button 

20 VB2 gets selected. Then the "Subtitle Language" button VB2 
was activated e.g. by the user pressing an "OK" button on 
the remote control. The effect is that the four buttons BGS 
to the right are rendered, presenting subtitle options, and 
in particular these buttons are rendered in the same 

25 positions as the four buttons BGA to the right were 

rendered for audio options in Fig. 2. This corresponds to 
the third possibility for positioning buttons of button 
groups, as described above, since buttons that have the 
same position but belong to different submenus belong to 

30 the same button group. The buttons BGS shown in Fig. 3 are 
different from the buttons BGA shown in Fig. 2, since they 
have different functions, namely allow selection of a 
subtitle language. The buttons BGS represent the "Subtitle" 
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range of buttons for each of the button groups, while the 
buttons BGA in Fig. 2 represent the "Audio" range of buttons 
of the same button groups. In this particular example, not 
only the position but also the appearance and the languages 

5 of the corresponding buttons of the shown submenus are the 
same. E.g. in Fig. 3, only from the selected button VB2 is 
visible to which submenu the buttons BGS refer. Therefore, 
when one of the submenu buttons BGS is selected, the 
corresponding superior button VB2 should look different 

10 from an unselected button, though it is neither selected 
nor activated. 

Fig. 4 shows a menu where a graphical user hint GH, in the 
form of a small arrow, appears in the visible buttons 

15 VB1,VB2, showing that related submenus exist. When the 
"Audio Language" button VBl is activated or when it is 
selected and the RIGHT button is pressed on the remote, 
then its button handler selects an invisible button INB 
being defined in the neighbourhood information of the 

20 "Audio Language" button VBl as neighbour to the right. The 
invisible button INB is a so-called auto-action button, 
since it automatically switches from the selected state to 
the activated state, so that its button handler is 
executed. The button handler comprises a command to render 

25 the four buttons BGA on the right visible, without any of 
them being activated, and a command to select the "English' 
button. The invisible button INB has the same data 
structure as the other buttons. If the RIGHT button is 
pressed while the "Audio Language" ' button is selected, the 

30 audio options become visible. 

In the next step, one of the new buttons on the right can 
be selected, as shown in Fig. 5. There are four different 
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button groups BGA, namely ^English' , x Japanese ' , ^Korean' 
and x Dutch' . Further, it is possible that the "Audio 
language" and the "Subtitle Language" buttons belong to 
button groups. It is also possible though to combine button 

5 groups and single buttons. From the data structure point of 
view, single buttons may also form a button group with only 
one element. In the situation depicted in Fig. 5, the "Audio 
Language" button looks selected or activated, and for each 
of the submenu button groups BGA the buttons representing 

10 the options for audio are enabled and visible. They are 

rendered at the same positions where also the buttons for 
subtitle options would be rendered, if the "Subtitle 
Languages" were selected. Therefore the buttons belonging 
to the same button group are overwriting each other. One of 

15 the submenu buttons is selected, and therefore the "Audio 

Language" button must be deselected, as described later for 
Fig. 23. The selected submenu button can be a default 
button, e.g. ^English' is a predefined default, or it can 
be the currently used option, or any other type of default. 

20 

Fig. 6-8 show examples for the three above-mentioned 
possibilities for defining button group areas. The area of 
a button group is generally defined through the sum of all 
on-screen areas of the buttons that belong to that button 

25 group. Further, the position of different buttons that 

belong to the same button group may differ, as long as they 
are within the area specified for their button group. For 
practical reasons, i.e. due to the column and row structure 
of a typical display, the button group area and partial 

30 areas will usually be rectangular, though they can in 
principle have any shape. 
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Fig. 6 shows the first possibility for definition of a 
button group, as described above. A first button group BG61 
comprises three buttons B#1,B#4,B#6 with three separate, 
non-coherent areas. A second button group BG62 also 

5 comprises three buttons B#2,B#3,B#5 with three separate, 
non-coherent areas. According to the definition of button 
groups, not more than one button per button group BG61, BG62 
is enabled at a time, and may be visible. Thus, only one of 
the buttons B#1,B#4 and B#6, and only one of the buttons 

10 B#2,B#3,B#5 may be enabled (and visible) at a time, while 
the others are rendered transparent. Further, none of the 
individual button areas of the first button group BG61 may 
overlap with any individual button area from the other 
button group BG62. It is possible though to surround, even 

15 fully surround, a button group area of a first button group 
with partial areas belonging to a second button group. In 
this example, the enabled and visible buttons fully cover 
their respective button group areas. In another embodiment 
though it would be possible that areas of buttons that 

20 belong to the same group may overlap, e.g. B#2 and B#5. 

This is because they may not be visible at the same time, 
and when one of them is rendered visible, all partial areas 
of the button group area are re-rendered and thus cleared, 
i.e. rendered transparent. 

25 

Fig. 7 shows the preferred embodiment, where a single area 
is defined for every button group, and all buttons 
belonging to that button group are positioned within that 
area. A button group BG71 has a defined area where all its 
30 buttons B#ll, B#12 are rendered. Another button group BG72 
has another area for its buttons B#21, B#22 . Also here, 
button group areas of different button groups may not 
overlap. The position of different buttons B#11,B#12 that 
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belong to the same button group BG71 may differ, as long as 
they are within the specified area. 

Fig. 8 shows a special case of the preferred embodiment, 
5 where all buttons of each button group have exactly the 

same position, thus overwriting each other. Therefore, the 
area of a button is identical with the button group area in 
this case. A first button group comprises an enabled, and 
therefore visible, "Audio Language" button BG81 and one or 
10 more disabled, invisible buttons BG81' . Though the disabled 
buttons BG81' are drawn visible in the figure for clarity, 
they have exactly the same display position as the visible 
button BG81. 

15 Fig. 9 shows an example where a menu is represented only 

through a menu icon MM, while the rest of the screen shows 
an audio-visual presentation, e.g. a movie. A small icon MM 
is displayed on the screen, indicating that a menu is 
available. The icon MM does not disturb the viewer who is 

20 watching a movie. When the viewer activates the menu, e.g. 
through pressing either a dedicated button or the "OK" 
button on the remote control, further buttons of the menu 
are revealed, as shown in Fig. 10. The user can operate the 
menu to make selections, e.g. select an audio language or a 

25 subtitle language with respective buttons AL,SL. If e.g. 
the "Audio Language" button AL is selected and activated, 
an audio language submenu is rendered visible, as shown in 
Fig. 11. It may comprise e.g. the "Audio Language" button 
AL1, to indicate the current position within the 

30 hierarchical menu, and initial language option buttons 

L1,.,.,L4 for English, Japanese, Korean and Dutch. The "Audio 
Language" button AL1 has an indication Mil for indicating 
that further options exist. In this example, the further 
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options can be accessed by repeated activation of the 
* Audio Language" button AL. This is called multi- 
activation. If this button AL is activated a second time, 
audio language buttons L5,...,L8 for Spanish, French, Greek 
and Polish appear, and after a third activation there are 
audio language buttons L9,...,L12 for Danish, Norwegian, 
Finnish and Swedish. After a fourth activation of the 
"Audio Language" button AL however the initial menu is 
displayed again, as shown in Fig. 10. The menu can be 
iconified again with the dedicated menu button. 

Although the viewer has the impression that only the text 
within the option buttons changes, it is technically 
difficult and error-prone to program such a menu with known 
methods and data structures. In particular, for the 
verification of the programmed menu data it is necessary to 
test all possible combinations of buttons, in order to be 
sure that the menu works correctly. An implementation using 
button groups according to the invention is advantageous, 
because the menu needs to be verified with only one button 
from each button group, and the button group mechanism can 
be verified separately, only once. Further, it is easy for 
the menu programmer to rearrange the options, and thus 
modify the button groups. 

In the described example, a first button group comprises 
the buttons for English Ll, Spanish L5 and Danish L9. 
A second button group comprises the buttons for Japanese 
L2, French L6 and Norwegian L10. 

A third button group comprises the buttons for Korean L3, 
Greek L7 and Finnish Lll. 

A fourth button group comprises the buttons for Dutch L4, 
Polish L8 and Swedish L12 . 
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Those buttons of the different button groups that are 
enabled and visible at the same time can be regarded as a 
logical layer, though from the data structure point of view 
they are independent from each other. They are only at the 
5 same time enabled and visible. 

But also the "Audio Language" button AL is not a single 
button, since depending on the current state of the other 
menu buttons it has different functions. Particularly, the 

10 functions differ in which option buttons must be enabled 
upon activation of the current "Audio Language" button. 
E.g. activation of the "Audio Language" button ALl in 
Fig. 11 causes that the option buttons L5,...,L8 shown in 
Fig. 12 are enabled, while activation of the identical- 

15 looking "Audio Language" button AL2 in Fig. 12 causes that 
the option buttons L9,...,L12 shown in Fig. 13 are enabled. 
Therefore, a fifth button group may comprise the different 
"Audio Language" buttons ALl, AL2, AL3 that belong to the 
logical layers. Alternatively, it is possible that the 

20 "Audio Language" buttons ALl , AL2 , AL3 are identical, and the 
button command takes into account which button from the 
button groups are currently enabled, and the command 
enables the next element from each button group. 

25 Fig. 14 shows an example for conditional enabling. Buttons 
can be enabled or disabled depending on user settings or 
player settings. E.g. there can be three versions of a 
movie on a disc: a 'children's cut', a 'theatrical cut' and 
a 'directors cut' . When the disc is inserted into the 

30 player, the initial menu may show a non-selectable button 
NSB with e.g. the title of the movie, and three selectable 
buttons SB1,SB2,SB3 for the reproduction options. A user 
can however set a parental level, and thus allows the 
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'children's cut 7 and the 'theatrical cut' f but rejects the 
'directors cut' . The screen may then show only two 
selectable buttons SB1,SB2 for the two allowed options. For 
the forbidden option however there is no visible button 
5 available, since it is rendered transparent. 

According to the invention, this menu behaviour can be 
technically achieved by using enable/disable commands and 
button groups. One or more of the option buttons SBl, SB2, 
SB3 may belong to separate button groups, and according to 

10 specified settings for each button group a defined member 
is enabled and rendered visibly. In the current example, 
the "Director's cut" button belongs to a button group SB3 
according to the invention, with an associated button group 
area, and the parental level setting of the player causes 

15 the initial button handler to disable the respective 

button, i.e. to render the button group area transparent. 
Also other setting types can be utilized, e.g. reproduction 
options depending on player type, audio equipment type etc. 

20 As a further embodiment of the invention, so-called 

breadcrumb menus can easily be constructed. Breadcrumb 
menus are generally menus where the previously pressed 
button that belongs to another hierarchy remains visible , 
so that the user can see which button was selected, and to 

25 what the currently displayed option buttons refer. This is 
particularly useful for hierarchical menus. In the data 
structure utilized by the invention, hierarchy is given 
implicitly by neighbourhood relations. 

30 Fig. 15 shows a menu screen with three buttons AMB, ALMB, SLMB 
that belong to the same hierarchical level. One of the menu 
buttons AMB is for multi-angle selection. It is selected, 
and three angle select option buttons ASB are displayed on 



WO 2005/069109 PCT/EP2004/014187 

19 

the right. Each of these visible option buttons ASB belongs 
to a separate button group and was rendered visible because 
the "Angle" menu button AMB is selected. The other members 
of these button groups are disabled and thus invisible. 

5 

Fig. 16 shows that the menu comprises also other, invisible 
buttons IBl,..., IB4. These are used to define what should 
happen at transitions between the higher level menu buttons 
AMB, ALMB, SLMB . 

10 

When the "Angle" menu button AMB is selected, like in 
Fig. 15, and the user wants to select the "Audio Language" 
menu button ALMB, he presses the DOWN button on his remote, 
because the "Audio Language" menu button ALMB is displayed 

15 below the "Angle" menu button AMB. A dynamic menu, as 
supported by the invention, may perform the following: 
First, the button that is defined as DOWN neighbour of the 
"Angle" button is selected, which is in this example an 
invisible button IBl. This is the state shown in Fig. 17. 

20 Although invisible buttons are not represented on the 

display, they may have a display area or position assigned 
due to data consistency, e.g. if the same data structure is 
used for visible and invisible buttons. For illustrative 
purpose however the figures show also invisible buttons, at 

25 their logical positions. 

Then, after the invisible button IBl was selected, it is 
automatically activated ( aut o__act ion^f lag==t rue in Tab.l), 
and its button handler executes the following commands: 
30 first it disables the menu option buttons ASB relating to 
the "Angle" menu button AMB, thus making them invisible, 
second it enables the option buttons ALSB that belong to 
the menu button the user wants to select, which is the 
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"Audio Language" menu button ALMB, and finally it selects 
the "Audio Language" menu button ALMB, thereby deselecting 
itself. This is shown in Fig. 18. Fig. 19 and Fig. 20 show the 
corresponding transition from the "Audio Language" menu 
5 button ALMB to the "Subtitle Language" menu button SLMB 
using another invisible button IB3, wherein the audio 
language submenu buttons ALSB are replaced by subtitle 
language submenu buttons SLSB. Further, there are invisible 
buttons IB2,IB4 for the opposite transitions. 

10 

As a result, the menu option buttons ASB, ALSB, SLSB always 
match the selected menu button AMB, ALMB, SLMB without the 
selected menu button being activated. The user may not 
perceive the intermediate states, the invisible buttons or 

15 the short time the described transitions take, usually in 
the range of milliseconds. According to the invention, the 
menu option buttons ASB, ALSB, SLSB are implemented as 
members of button groups. Buttons on the same position that 
belong to different submenus form a button group. This 

20 allows an easy menu data structure and therefore simplified 
programming and verification. In particular, button groups 
may implicitly handle the disabling of obsolete submenu 
option buttons and the enabling of the correct submenu 
option buttons that belong to the newly selected menu 

25 button. Since not more than one button from a button group 
may be enabled, and therefore visible, it is sufficient to 
select for each button group the new button to be enabled. 
This implicitly disables the previously enabled button of 
the group, and the pixels that belong to the button group 

30 area are overwritten according to the bitmap representation 
of the new button. The rest of the display may remain 
unchanged. Therefore there is no need for the decoder to 
analyse which buttons were visible before, which button 
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must be replaced,, which area it occupied and if any button 
areas overlap . 

Another embodiment of the invention, being an exemplary 
5 implementation of the above-described breadcrumb effect, is 
shown in Fig. 21-23. When a hierarchical menu button is 
selected, e.g. the "Angle" menu button AMB1 in Fig. 21, it 
changes from the normal state to the selected state, and 
its representation looks different, e.g. highlighted. This 

10 is caused by different bitmap representations corresponding 
to the states of a button. When the "Angle" menu button 
AMB1 is activated, it remains only a very short time in the 
activated state. Its appearance during this time may differ 
from the selected state, but the user will hardly see it. 

15 When the button is activated, its button handler may select 
an invisible button INB that is used to render the submenu 
buttons ASB visible, as described above. This situation is 
shown in Fig. 22. At this time, when the invisible button 
INB is in the selected state, the "Angle" menu button is 

20 not selected, since only one button of the menu can be 

selected at a time - otherwise the decoder could not detect 
to which button a user command refers. The "Angle" menu 
button is in the normal state instead. But in order to 
achieve the breadcrumb effect, i.e. indicate the menu 

25 button to which the current submenu buttons ASB refer, it 
would be desirable to give the menu button AMB1 another 
appearance. This can be achieved with the button groups 
according to the invention, e.g. by generating an "Angle" 
button group. 

30 

The default "Angle" button AMB1, like any menu button, has 
the three states normal, selected and activated. Another 
button, e.g. an "Angle_jSelect" button AMB2 belonging to the 
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same button group looks similar to the default "Angle" 
button AMB1 and has the same display position, but differs 
slightly. E.g. its normal state bitmap may be the same as 
the default buttons selected or activated state bitmap. As 
5 described before, the invisible button INB is automatically 
activated upon selection. It may e.g. render the submenu 
buttons ASB visible, then enable the "Angle_Select" button 
AMB2 (in the normal state) , thus implicitly disabling the 
previously visible "Angle" button AMBl, and finally select 

10 one of the submenu buttons ASBl, thus deselecting itself. 
This is shown in Fig. 23. The effect is that the user may 
recognize the button AMB2 as the same button AMBl like 
before, and that the button AMB2 looks selected or 
activated, but actually it is deselected. This allows 

15 giving a button virtually more different representations 

than states, e.g. colours, shapes, text etc., by replacing 
it with other buttons. The inventive button groups allow an 
easy handling of these buttons, and provide a simple 
mechanism to determine the correct values for pixels within 

20 the button group area. 

The group structure provides information for the menu 
decoder, the information defining which on-screen area 
needs update. Because within a button group not more than 
25 one button is active at a time, the activation of another 

button within a group implies the deactivation of the first 
button of the same group. This is an advantage for 
authoring, since it makes it easier to author menus. 

30 Especially in the case of prerecorded media, e.g. 

prerecorded Blu-ray discs, a verification process is 
performed on any title before it is released to check if 
the data-structure meets the specification. The invention 
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allows for easy verification while providing enhanced 
features to the content author when creating dynamic menus. 

In the following,- the syntax of a data segment shown in 
5 Tab.l is described, which may be contained in a bitstream 
and describes the initial menu screen, being an exemplary 
implementation. It describes the case that the button group 
area is defined according to the second possibility 



described above. 

10 

Tab.l : Exemplary Syntax of data segment describing a menu 





Syntax 


No. 

of 

bits 


Mnemonics 










interactivecompositionsegment() { 






2 


segmenttype 


8 


bslbf 


3 


segmentlength 


16 


uimsbf 


4 


composition_number 


16 


uimsbf 


5 


compositionstate 


2 


bslbf 


6 


reserved 


6 


bslbf 


7 


command_update_flag 


1 


bslbf 


8 


reserved 


7 


bslbf 


9 


composition time out pts 


33 


uimsbf 


10 


reserved 


7 


bslbf 


11 


selection time out pts 


33 


uimsbf 


12 


reserved 


7 


bslbf 


13 


UO mask tableO 


64 


bslbf 


14 


animation frame rate code 


8 


uimsbf 


15 


default selected button number 


8 


uimsbf 


16 


default activated button number 


8 


uimsbf 


17 


while (processed length < segment length) { 






18 


button_group() { 






19 


button group horizontaljposition 


16 


uimsbf 


20 


button group vertical position 


16 


uimsbf 


21 


button group horizontal_size 


16 


uimsbf 


22 


button group vertical size 


16 


uimsbf 


23 


default enabled button number 


8 


uimsbf 


24 


num buttons 


8 


uimsbf 


25 


for (i=0; i<num_buttons;i++) { 






26 


button number 


8 


uimsbf 


27 


numerically_selectable_flag 


1 


bslbf 


28 


reserved 


7 


bslbf 


29 


auto_action_flag 


1 


bslbf 
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30 


reserved- 


7 


bslbf 


31 


button horizontal position 


16 


uimsbf 


32 


button vertical position 


16 


uimsbf 


33 


neighbor info() { 






34 


upper button number 


8 


uimsbf 


35 


lower button number 


8 


uimsbf 


36 


left button number 


8 


uimsbf 


37 


right button number 


8 


uimsbf 


38 








39 


normal state info() { 






40 


start object id normal 


16 


bslbf 


41 


end object id normal 


16 


Lbslbf 


42 


repeat normal flag 


1 


bslbf 


43 


reserved 


7 


bslbf 


44 


} 
> 






45 


selected state info() { 






46 


start object id selected 


16 


bslbf 


47 


end object id selected 


16 


bslbf 


48 


repeat selected flag 

Jr — 5» ■ — 


1 


bslbf 


49 


reserved 


7 


bslbf 


50 


} 






51 


actioned state info() { 






52 


start obiect id activated 


16 


bslbf 


53 


end obiect id activated 


16 


bslbf 


54 


> 






55 


nu in of button commands 


8 


uimsbf 


56 


forf cmd id " 0* 

cmd id < num of button commands; 
cmd id++ ) { 






57 


button commandfemd id] 


96 


bslbf 


58 


} 






59 


} 






60 


} 






61 


} 






62 


} 







Tab.l : Exemplary Syntax of data segment describing a menu 



5 The notation used in Tab.l uses while-loops and for-loops. 
Loops however are only a means to generalize the notation, 
since the actual bitstream will include data for the single 
passes or instances of the loop. 
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Between 1.17 and 1.61 is a loop over the complete data 

segment of length segment__length . A data segment may 
include any number of button groups . 

5 In 1.18 is defined that the following lines, until 1.60, 
refer to the definition of a button group. The identifier 
of the group is the value given in round brackets. In 
1.19-22 the respective position on the screen is defined 
for the current button group, also referred to as button 

10 group area in this application. It is defined by its 
horizontal and vertical size and the position of its 
reference point. In this case the button group area is only 
one rectangular, but as described before it may be other 
areas or a plurality of rectangulars . In that case 1.19-22 

15 would be repeated once for each partial area. 

The parameter in 1.23 defines which of the buttons of the 
current group is enabled by default. The decoder uses this 
value to initially load a register that relates to the 

20 current group and holds a variable. This variable specifies 
the number of the currently enabled button, and can be 
modified during operation of the menu. It may also be 
assigned a value that corresponds to none of the buttons, 
so that all buttons of the group are disabled. This 

25 mechanism ensures that not more than one button within a 
group is enabled. Two other parameters that are used to 
initialize variables that may be modified during menu 
operation are def ault_s elect ed_button_n umber (1.15) and 
default activated button number (1.16). 



In 1.24 the number of buttons in the current group is 
defined. 



WO 2005/069109 PCT/EP2004/014187 

26 

The loop beginning in 1.25 covers all buttons of the group 
and defines for each button a reference number (1.26), if 
it is numerically selectable (1.27), if it automatically 
executes its commands when it is selected (1.29), its 

5 position within the button group area (1.31-32), its 

neighbour buttons (1.33-38), and address ranges indicating 
where the bitmap representations corresponding to the 
different buttons states can be read. For every button, one 
or more commands can be defined. The number of commands of 

10 the current button is specified in 1.55 by the parameter 
num_of__button_commands . The actual commands of the button 
handler are defined in 1.56-58. 

The invention is usable for all kinds of presentation 
15 devices that have access to a display and contain a decoder 
for processing menu data structures read from e.g. DVDs, 
Blu-ray discs or other media. Further, the invention is 
usable for generating such data structures. 

20 According to the invention, a decoder for decoding a data 

stream, the data stream comprising menu data for a visually 
displayable menu, and the menu comprising separately 
rendered menu items including selectable menu buttons, 
includes (i) means for defining at least one group of menu 

25 items, the group comprising one or more menu items, wherein 
a menu item may not belong to more than one group, (ii) 
means for associating to said group a defined area on the 
display, and (iii) means for assigning a state to each of 
said menu items belonging to a group, the state being 

30 "enabled" or "disabled", wherein only an enabled menu item 
may be displayed, and wherein not more than one menu item 
within a group may be enabled simultaneously. 
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Further, a displayed menu item that belongs to a group is 
displayed within the area associated with said group, 
wherein the areas of different groups may not overlap and 
no display pixel may belong to more than one group. 

Further, a menu item may have an associated command, which 
is executed upon activation of the menu item and comprises 
enabling or disabling of another menu item. 



